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ABSTRACT 

-  The  modelling  and  programming  philosophy  behind  micro-computer 
software  used  in  teaching  simulation  is  presented  with  implementations 
in  FORTRAN-80 ,  Pascal/MT+  and  Janus  (an  Ada  subset).  The  relative 
strengths  and  weaknesses  of  these  implementations  are  discussed. 
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SIGNIFICANCE  AND  EXPLANATION 


At  the  University  of  Wisconsin-Madison  we  have  successfully  used  micro¬ 
computers  for  several  years  in  our  graduate  level  simulation  courses.  After 
some  initial  start  up  problems,  mostly  caused  by  our  failure  to  realize  that 
micro-computers  are  not  used  in  the  same  manner  as  main  frames,  we  feel  that 
we  are  able  to  teach  simulation  at  least  as  effectively  with  micros  as  we 
once  were  with  our  larger  computers.  One  reason  for  this  is  our  development 
of  a  simulation  "language"  specifically  designed  for  use  in  an  educational 
environment  by  "naive"  users. 

In  spite  of  our  success  in  using  micro-computers  for  simulation  for 
education,  we  have  been  having  difficulties  answering  reasonable  questions 
regarding  the  utility  of  micro-computer  based  simulations  in  non-educational 

settings.  Typical  concerns  include  issues  such  as: 

1.  Are  micro-computers  too  slow  for  serious  simulations? 

2.  Is  sufficient  memory  available  for  large  models? 

3.  Which  programming  language  is  best  suited  for  model  development? 

In  this  paper  we  will  attempt  to  provide  answers  to  these  questions. 

To  provide  for  a  fair  comparison  between  different  programming  languages 
we  designed  a  simple  discrete  event  simulation  language  with  many  of  the 
modelling  features  of  more  elaborate  languages.  This  language  was  then  imple¬ 
mented  in  Microsoft  FORTRAN,  Pascal/MT+,  and  Ada/ Janus,  and  the  performance 
of  these  implementations  were  compared. 

The  target  language  is  presented  in  Section  II.  The  three  implementations 
are  discussed  in  Section  III,  and  the  evaluation  of  the  implementation  is  pre¬ 
sented  in  Section  IV.  The  source  codes  of  the  three  implementations  are 
available  in  a  separate  document  112] . 


The  responsibility  for  the  wording  and  views  expressed  in  this  descriptive 
summary  lies  with  MR C,  and  not  with  the  authors  of  this  report. 
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I-  INTRODUCTION 

At  the  University  of  Wi sconsi n-Madi son  we  have  successfully  used 
micro-computers  for  several  years  in  our  graduate  level 
simulation  courses.  After  some  initial  start  up  problems,  mostly 
caused  by  our  failure  to  realize  that  micro-computers  are  not 
used  in  the  same  manner  as  main  frames,  we  feel  that  we  are  able 
to  teach  simulation  at  least  as  effectively  with  micros  as  we 
once  were  with  our  larger  computers.  One  reason  for  this  is  our 
development  of  a  simulation  “language"  specifically  designed  for 
use  in  an  educational  environment  by  "naive"  users. 

In  spite  of  our  success  in  using  micro-computers  for  simulation 
for  education,  we  have  been  having  difficulties  answering 
reasonable  questions  regarding  the  utility  of  micro-computer 
based  simulations  in  non-educational  settings.  Typical  concerns 
include  issues  such  as: 

1.  Are  micro-computers  too  slow  for  serious  simulations? 

2.  Is  sufficient  memory  available  for  large  models? 

3.  Which  programming  language  is  best  suited  for  model 
devel opment? 

In  this  paper  we  will  attempt  to  provide  answers  to  these 
questions. 

To  provide  for  a  fair  comparison  between  different  programming 
languages  we  desiqned  a  simple  discrete  event  simulation  language 
with  many  of  the  modelling  features  of  more  elaborate  languages. 
This  language  was  then  implemented  in  Microsoft  FORTRAN, 
Pascal /MT-t-,  and  Ada/Janus,  and  the  performance  of  these 
implementations  were  compared. 

The  target  1 anguaqe  is  presented  in  Section  II.  The  three 
implementations  are  discussed  in  Section  III,  and  the  evaluation 
of  the  implementations  is  presented  in  Section  IV.  The  source 
codes  of  the  three  implementations  are  available  in  a  separate 
document  C123. 
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the;  t#=%f<ge:t  language-: 


A.  Design  Goals 

The  purpose  of  any  simulation  language  is  to  tree  the  analyst 


■from  coding  tasks  so  that  she  can  concentrate  on  model 
development  and  analysis.  Here,  this  global  goal  was 
operati onal i zed  by  specifying  modelling  capabi 1 i ti es,  interface 
goals  and  resource  restrictions  as  follows: 

♦ - - 

!  DESI6N  OBJECTIVE  ! 

♦ - - - ♦ 

!  NODELL I N6  CAPABILITIES  (general  purpose)  ! 

♦ - - - - 

i  -  Discrete  event  scheduling  using  user  uritten  event  routines  ! 

I  A. .A _ i:. _ 1 _ _  /  _ A  _ A_  I 


-  Autoaatic  scheduling  of  recurrent  events 

-  Floating  point  clock 

*  Set  aodeliing  capabilities  with  autoaatic  data  collection 

-  Service  routines  for  collection  and  display  of  user 
specicfied  data. 

-  keyboard  control  of  running  aodels. 

-  Five  coaaon  randoa  nuaber  generators 


♦ - - - + 

;  USER  INTERFACE  (user  friendly)  i 

t - - - ♦ 


i  -  The  user  should  not  need  to  understand  the  design  of  the  i 

!  siaulation  data  base.  S 

!  -  The  user  should  not  be  able  to  cause  run  tiae  errors  in  I 

I  the  siaulation  package  (for  exaaple  by  reaovtng  a  non  i 

i  existing  entity).  i 

!  -  The  resulting  code  should  be  a  self  docuaented  aodel  ! 

I  -  Host  language  should  be  designed  to  facilitate  prograa  debugging  i 

1  -  Model  verification  should  be  facilitated  by  extensive  error  : 

)  checking  and  an  interactivly  controlled  trace  feature.  I 

+ - — - — - ...... - — — ......+ 

i  RESOURCE  CONSIDERATIONS  (run  on  8  bit  aicros)  ! 

♦ — - — - 1 

I  -  The  language  should  be  saall  enough  to  alloa  rooa  for  ) 

i  reasonably  coaplex  aodels  on  a  o4k  byte  aicro-coaputer.  ! 

!  -  Tiae  required  to  coapile  and  link  a  aodel  should  be  ! 

!  sufficiently  saall  to  facilitate  interactive  aodel  developaent  ! 

!  on  a  CF/H  based  desk  top  coaputer.  i 

i  -  Tiae  to  execute  a  aodel  should  not  be  excessive.  i 

♦ - - — » 


Table  1:  Design  Objectives. 


The  commands  of  a  language  intended  to  implement  these  objectives 
are  listed  in  Table  2.  To  keep  the  size  o+  the  system  small,  some? 
desirable  features  were  omitted.  For  example: 


-  Model  building  blocks  such  as  facilities  and  inventories 
are  omitted. 

-  All  sets  are  ranked  on  the  first  attribute  value 

-  Entities  can  only  be  removed  trom  the  head  of  a  set 

-  Simple  linearly  linked  lists  are  used  to  represent  all  sets. 

-  Only  the  most  common  random  number  generators  are  provided. 


Experience  has  shown  that  most  commonly  encountered  model 
features  can  be  easily  programmed  with  the  tools  provided  by  this 
language.  In  t  tie  few  cases  where  tins  was  difficult,  it  was  easy 
to  add  the  i  eguired  <  natures. 
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!*£VENT  SCHEDUL 1  NS ~COHHAMDS  "Effect "on'siiuUt^n'iiodel .  ! 

i  NextEvent  i  Updates  siaulation  clock  and  global  variables  TNow  and  Code 

♦ - - - - - + - - - - - - - - — — —  —  —  -  — — ♦ 

!  Recurrent (EventCode, Mean  Interval)  !  Schedules  perpetual  sequence  of  events  of  type  EventCode  at  expo-  : 

!  !  nentially  distributed  randon  intervals  mi th  a  aean  ot  Meanlnterval I 

♦ - + - 1 

!  Schedule  (EventCode, Tiaelncreaent) !  Schedules  a  single  occurence  ot  an  event  ot  type  EventCode  to  : 

•  !  take  place  Tiaefncraent  tiae  units  troa  current  siaulated  tiae. 


SET  MANAGEMENT  COMMANDS 


i  InsertlntoiSetNo, Attributes) 


!  ReaoveFroa(SetNo, Attributes) 


i  SizelSetNo) 


i  Ettect  on  the  siaulation  aodel  ! 

1  Inserts  the  entity  described  bv  the  vector  Attributes  into  the  set! 

I  SetNo  ,  such  that  the  first  attribute  value  for  set  aeabers  are  ! 
I  ranked  in  increasing  order  ! 

-♦ - - 

!  Reaoves  the  entity  at  the  head  of  the  set.  Returns  its  attribute  ! 
i  values  in  the  vector  Attributes  i 

-t - ♦ 

!  Returns  the  count  of  entities  currently  in  set  SetNo  ! 


i  RANDOM  NUMBER  GENERATORS 

1  Distribution 

1  Type  ! 

!  Bernoulli (p) 

i  Bernoulli  with  aean  *p‘ 

!  Integer  ! 

!  Exponential (taean) 

i  Exponential  with  aean  ‘aean’ 

i  Real 

I 

!  Noraal (aean, stdv) 

1  Noraal  with  aean  'aean'  and  standard  deviation  'stdv' 

!  Real 

1 

1  Poisson (laabda) 

!  Poisson  with  aean  'laabda* 

1  Integer  ! 

!  Unifora(a,b) 

!  Unifora  between  'a'  and  V 

!  Real 

!  OTHER  COMMANDS 

1  Function 

!  Collection,  value) 

1  Collect  point  values 

!  Histograa(value) 

1  Collect  data  for  histograa 

!  Initialize 

1  Initialize  entire  data  base 

i  Report 

1  Display  statistical  suaaaries 

1  Tiaelntegrate(Bin,NeuValue) 

!  Collect  data  for  tiae  integrated  averages 

Table  2:  Commands  Supported  by  Target  Language 


Events: 


V  f - ♦  t - «•  V 

it  . >!Naiting  Line! - >!  Server  is)  ! - > 

♦ - *  f - ♦ 

c  ’it’  ’SS’ 

Figure  1:  Process  MocJei  of  N-Server  Queuing  svstem. 


1 

J 


B.  An  Example 


To  introduce  our  simple  language,  we  present  in  Proqram  1,  a 
simulation  model  of  the  n -server  queuing  system  described  in 
Figure  1. 

♦ - ♦ 

I  START  i 
♦ - ♦ 


♦  — - 

I  INITIALIZE  i 

t  I 

I  I 

+ - f 


f - ♦ 

!  DETERMINE  TINE  !<-♦ 

i  OF  NEIT  EVENT,  !  i 

>  I  i 

!  EXECUTE  IT  !  1 

f - ♦  { 

■  i 

i  i 

*  - +  yM  [ 

:  more?  : - ♦ 

♦  - ♦ 

!no 

♦ - ♦ 

i  PRINT  SUNNARY  ! 

♦ - ♦ 


Procedure  Arrival  Procedure  Departure  Procedure  Serve(EntryTiie) 

beam  beam  begin 

IF  Si zeOF i ’ SS’ ) cSer verCount  ReaoveFroei’SS’ .EosJEntry)  ServiceTiae=Expo(NeanTi«e) 

then  Collect (2, TNou-TEntry)  InsertlntoCSS’ ,TNo**STme,EntryTme) 

Insertlntoi’NL’ ,TNoh)  iF  SizeflF(’NL’)  >0  then  Schedulei’DE’,ServiceTiae) 
else  ReioveFro«(’NL’,TEntry)  end 

Serve (TNou) 
end 

end 


Program  1:  Target  model  of  N-berver  Queuing  System 


The  overall  logic  of  this  model  should  be  obvious  and  is  not 
discussed  here.  Note  that  we  chose  to  use  an  Algol -like  block 
structure  in  this  model.  Obviously  the  program  structure  used  in 
any  implementation  ot  the  language  is  a  Function  oF  the 
structures  supported  bv  the  host  language. 


Statistics  collected  on  sets  Current  tme  is  =  100.00 


Set 

Total 

Current 

- Tme-ln-Set 

— 

Avg. 

No 

Input 

size 

ain  avg 

■ax 

size 

SS 

14 

0 

0.13  0.32 

0.69 

0.45 

NL 

4 

0 

0.06  0.12 

0.25 

0.05 

Statistics  on  user  collected  data  Current  tme  is  =  100.00 
Unit  085  Nean  Var  StDev  Nin  Nax 

1  4  0.12  0.01  0,09  0.06  0.25  i  Tme  in  queue  J 

2  14  0.36  0.03  0.  17  0.13  0.69  i  Tme  m  systee  > 

Figure  2:  Output  From  Program  1. 


Collectil.Tnou-TEntryl 

ServeiTEntry) 

endiF 


Initialize 

RecurrenU’AE’,TArnv) 
ServerCount  =  n 
Schedule(’lE’,TFini 


Repeat 
NextEvent 
Case  Code  oF 
’ AE’ lArrival 
’DE’  -.Departure 
end 

until  ’LE' 

Report 
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The  statistical  summary  report  produced  by  this  model  is 
presented  in  Figure  2,  and  a  portion  of  the  trace  produced  by  the 
running  model  is  reproduced  in  Fiqure  3.  In  addition  to 
automatically  collected  data.  Figure  2  also  includes  summaries  on 
explicitly  collected  data  on  total  time  in  the  system  and  on  time 
in  queue. 


Tiie  Comnd 

Event 

Set 

n 

Unit 

Parameters 

0.0 

initialize 

Recurrent 

AE 

0.49 

o.so 

Schedule 

LE 

100.00 

0.0 

0.49 

Event 

AE 

Recurrent 

SizeOf 

AE 

SS 

0 

0.71 

0.50 

Insert  Into 

ss 

1 

0.78 

0.49 

Schedule 

DE 

0.78 

0.29 

0.71 

Event 

AE 

Recurrent 

SizeOf 

AE 

SS 

1 

1.39 

0.50 

Insert  Into 

ML 

1 

0.71 

0.78 

Event 

ReioveFroi 

DE 

SS 

0.78 

0.49 

Collect 

SizeOf 

ML 

1 

2 

0.29 

ReioveFroi 

ML 

0.71 

Collect 

1 

0.07 

Insertlnto 

SS 

1 

1.10 

0.71 

Schedule 

DE 

1.10 

0.32 

Fiqure  3:  Partial  trace  produced  by  the  model 
C.  MODELLING  CONSTRUCTS 


The  language  presented  here  is  based  on  the  GAbP  IV  language  [91. 
Details  of  the  language  are  discussed  below. 


1.  Events  and  Event  Scheduling 


The  act  ot  entering  information  about  future  events  in  the  future 
events  list  is  referred  to  as  Event  Scheduling.  h  typical  event 
list  is  shown  in  Fiqure  4.  Two  mechanisms  for  event  scheduling 
are  recognised.  These  are  discussed  below. 


Tiae 


!  Code 


:  203. 54  !  AE’ 


DE’ 


I  20i.<>7 

♦ - ♦ - 

i  1000.00  i  ‘IE’ 

t - + - 


Events 

Arrival  ot  custoier 
Departure  ot  custoier 
End  of  simulation 


Fiqure  4:  Typical  event  list. 


h  recurrent  event.  stream  is  a  sequent e  of  events  t such  as 
customer  ar  r  ivais;  that  occurs  at  random  intervals  independently 
ut  i  <•.-  state-  of  the  system  at  »nv  point  in  time.  these  events 
a I  1  v  .loser  i  Utr  o  :  r  or  nai  inputs  to  a  mixlel  suen  as  customers. 
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machine  breakdowns,  messages  etc.  In  Program  1  the  command 
Recurrent (‘ AE’ , TArri v)  is  used  to  schedule  a  perpetual  sequence 
of  type  'AE’  (arrival)  events  each  of  which  is  separated  from  its 
neighbor  by  an  exponentially  distributed  random  interval  with  a 
mean  of  TArri v. 

A  scheduled  event  is  one  that  is  explicitly  inserted  into  the 
events  list  by  the  user  written  model.  This  modelling  construct 
is  used  to  create  events  that  are  triggered  by  state  changes  in 
the  simulated  system.  In  our  example,  the  command 
Schedul  e  ( ’  DE '  ,  expo  (TServ)  )  schedules  a  ’DE’1  (departure)  event  to 
occur  expo(TServ)  time  units  from  the  current  simulated  time. 
Scheduled  events  differ  from  recurrent  events  in  that  they  are 
usually  created  when  the  state  of  the  system  a  certain  specified 
state.  Recurrent  event  streams  do  not  reflect  the  state  of  the 
system. 

2.  User  Defined  Sets  and  Entities 

The  set  modelling  construct  is  used  in  most  simulation  languages 
to  represent  and  hold  entities  as  they  flow  through  the  system 
beinq  simulated.  In  Program  1  we  use  the  set  JWL?  to  hold  the 
customers  in  the  waiting  line  and  the  set  ’SS’  to  hold  customers 
being  served. 

In  our  simple  language  all  sets  are  ranked  in  increasing  order  or 
the  first  attribute  of  each  entity.  In  Program  1  we  want  to  serve 
customers  in  the  order  they  arrive.  We  therefore  assign  the  time 
of  arrival  to  attribute  one  for  ail  customers  entering  the  queue. 
Similarly.  for  customers  entering  the  ’’being  served  set"  we 
assign  the  end-of -servi ce  time  to  the  first  attribute. 

Entities  can  only  be  removed  from  the  head  of  a  set.  This  is  the 
most  serious  shortcoming  of  the  present  design.  Our  decision  to 
exclude  routines  for  removal  of  entities  in  the  middle  ot  a  set 
was  due  to  the  increase  in  complexity  to  find  the  desired  entity 
(the  actual  removal  of  an  entity  when  its  position  is  known  is 
trivial > . 


D.  DATABASE  MANAGEMENT 

To  a  user,  a  simulation  language  may  be  thought  of  as  a  modelling 
tool.  To  the  l anquage  implementor  however.  it  looks  more  like  a 
data  base  management,  svstem.  This  is  because  an  elaborate  ciat.a 
base  is  required  to  keep  track  ot  the  constantly  changing  state 
ot  trie  simulated  stem.  In  the  following  we  discuss  the 
concept  uai  design  o«  this  structure. 

1.  Events  and  event  .->c  hedu  l  i  nu 

In ♦ nr  mat  i on  about  individual  events  are  contained  in  event  notices, 
e  a  i  bi  ut  wtu  h  i  ttiil  din1  i )  io  f  i  d  I  ow  1 1  ig  l  n  t  oi  mat  i  or  i  s 


1.  Time  of  the  event 

2.  Type  of  the  event 

3.  Mean  interval  between  recurrent  events 

To  ensure  proper  execution  of  events,  these  event  notices  are 
stored  <at  least  logically)  in  chr onol oqi cal  order  in  the 
simulation  data  base.  The  task  of  maintaining  the  notices  in  tins 
order  is  delegated  to  the  event  scheduling  commands  iTable  3). 


I  Function  I  Effect  on  event  set  I 

!  Next Event  »EventCode,Ti»ei  I  Retrieves  code  end  tiae  of  next  event  I 

I  I  in  list  and  deletes  the  corresponding  I 

I  I  event  notice  ! 

♦ - ♦ - ♦ 

!  Recurrent <EventCode,NeanInterval>!  Creates  event  notice.  Inserts  notice  ! 

I  I  at  proper  place  in  set  ! 

* - ♦ - ♦ 

i  Schedule  (EventCode,Tieelncre«ent) 1  Creates  event  notice.  Flags  event  as  ! 
i  I  nonrecurrent.  Insertes  in  set  i 


Table  3:  Effect  on  Event  Scheduling  commands  on  the  Database. 


The  design  of  efficient  data  structures  for  simulation  has  been  a 
subject  of  considerable  interest  in  recent  years  C2,5,7,13J. 
However  to  keep  our  language  simple,  the  only  data  structure  used 
in  this  project  is  the  linked  list.  Figure  5  shows  how  the  event 
set  in  Figure  4  can  be  represented  as  a  linked  list. 


V 

v - -♦  ♦ - ♦ 

I Type=Depirture!  ! Tvpe=EndOf Si iu ! 

•  Tim*  204.67!->!Ti«e=  204.67! 

! Interval^  0  !  ! Interval:  0  I 

♦  - ♦  ♦ - * 

I  A  I 

I  * 

{  f - 1 

♦ - - - 


♦  - f 

I 

I  Head 

i 

» 

♦  - ♦ 


♦ 


♦— - 1 

!Type=  Arrival ! 
ITiee*  203.54! 
!  Interval =3.00 ! 
♦ - , 


■t 


Figure  5:  Linked  List  Representation  of  Events  List  in  Figure  4. 

Since  the  detailed  implementation  of  data  structures  depends  on 
the  programming  language  used.  we  deter  the  spec l f i cat i ons  of 
record  format  and  content  for  event  notices  to  the  three 
implement  ion  sections. 

2.  User  Defined  Sets  and  Entities 

Individual  entities  are  represented  by  entity  records.  To  teep 
the  system  simple,  we  are  again  using  linked  lists  to  maintain 
the  recot  ds  in  pr  oper  order  .  To  tau  1  i  iate  automatic  coll  eel  i  on 
of  per  for  mance  data,  the  header  recor  d  tor  each  an  terent  set 
includes  space  ror  the  tol lowing  statistical  data: 
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1.  Number  of  entries  into  the  set. 

2.  Current  size  ot  the  set. 

3 .  Total  time  in  set  at  time  ot  last  state  change. 

4.  Time  ot  last  change  in  state  ot  set. 

5.  Maximum  time  an  entity  has  spent  in  the  set. 

6.  Minimum  time  an  entity  has  spent  in  the  set. 

In  Table  4  we  summarize  the  effect  of  different  set  management 
commands  on  the  simulation  data  base. 


Function 

!  Effect  on  the  data  structure  ! 

Insert  Into (SetNo, Attributes) 

!  Obtains  an  entity  record.  Saves  attribute  values  and  other  data. : 

!  Links  record  into  proper  logical  position  in  set.  • 

ReaoveFr  oa ( 5e t  No , Attributes) 

!  Roves  attribute  data  froa  entity  record  to  vector  Attributes.  ! 

1  Deletes  entity  record.  Collects  data  on  set  utilization  ■ 

Size(SetNo) 

!  No  effect  on  data  structure  ! 

Table  4:  Effect 

an  Database  of  Set  Management  Commam 

Language  Features!  Janus/Ada 

Dynaaic  Heaory  !  Ves 

Hanaqeaent  ! 

FORTRAN-80 

No 

Pascal/HT+ 

Ves 

Include  Files  !  Ves 

No 

Ves 

Separately  coap-  !  ¥es 

lied  library  ! 

Ves 

Ves 

• 

Strongly  Typed?  !  Ves 

No 

Ves 

Variable  Naaes  !  Any  Length 

6  char  aax 

8  signif.chr 

!  Variables  ! 


Double  Precision  ! 

No 

z+zzzzzzzzzz 

!  Yes 

i 

» 

No 

Real  Variables  ! 

No 

!  Yes 

i 

* 

Yes 

Record  Type  ! 

Yes 

;  No 

i 

i 

Yes 

Scope  of  vanabl.i 

Many  options!  Local, COHHQN! 

Nested 

Static  Variables  ; 

yes 

:  No 

No 

i  Resource  Reqats 


1  Floppy  bisks 

t - 

I  (tenor  y  Requires 


2  I  256k 
o4k 


2  I  80k 

04k 


2  t  256k 
64k 


i  Operating  Systea  : 


CP/J1  ;  CP'H  ;  CF/H  ; 


f  ah  l  *7’ 


u  i -;> L  1 1  Mji: , 1 1.  h  i  nq  Language  Feature1: 
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In  till?  section  we  present  the  implementations  of  the  tarqet 
language  in  the  three  different  programming  languages.  But  first, 
tor  readers  not  familiar  with  the  features  of  the  1 anquaqes  used 
in  t hi  1  s  report,  we  present  in  Table  5  '.page  S)  a  brief  summary  of 
important  features. 

A  summary  of  the  commands  used  in  our  i mp 1 ementat l ons  is  given  in 
Taole  6.  As  we  shall  see,  language  differences  have  an  important 
impact  on  the  manner  in  which  these  commands  are  implemented. 


Target  Language  1 

FORTRAN-30 

!  Pascal /NT+ 

1  Ada/ J  anus 

NextEvent  ! 
Recurrent (code, lean) ! 
Scheduletcode, liner) 

call 

call 

call 

NEiTEV 1 ievent)  !  NextEvent 

RECUR (lev, tiean)  !  Recurrent (code, Meanlntervail 

SCHEDUiiev, tinier) !  Schedule (code, intterval 1 

1  Next_E vent (Current  Event) 

!  Recurrent (Event  Code. Mean) 

;  Schedule(Code,Tlnter> 

Insert  Into (Set , Attr )  I 
ReioveFroiiSet.Attr)  I 
Size(Set)  1 

call  INSERT <i set , a> 
call  REMOVE ii set, a) 
NSIZE(iset) 

!  Insert I nto < set ) 

1  ReioveF roii  set) 

1  SizeGf(set) 

]  Insert  IntofSet  nuiber) 

1  Reiove'Frci (Set 'Nuiber i 
!  SizeJiT (Set  NuiBer) 

Collect (bin, value) 

Hi stogra* lvalue) 
Initialize 


call  COLCTii.x) 
call  ERROR < i > 
call  HISTGUi 
call  INIT 


Report  ! 

I 

I 

Tiae Integrate ibin, V) i 


call  REPOST 
call  TCOLCTU.nt) 


Collects BinNuaber , Value)  !  Collect (Bi n , Value) 


Histograi 

Initialize 


Report 

Tcollect  (Bin, Data) 
Bernoulli (p) 


i  initial i re_Events 
!  Initialize  Sets 
!  Initialize'Data  Collection 
i  Set  Report 
1  ColTect  Report 
;  TCollect (Bin, Value) 


Bernoulli (p) 
Exponential itiean) 
Noraal  nean.stdv) 
Poisson (laibdar 
Untfori(a,b) 


IBERNG(p) 

EiPDlti 

IPGISNia) 

UNlFiA.B) 


Bernouilnp) 
Expotdtean) 

Poisson  UaaPda) 

Unit (liiait,uliait) 


!  RandoitA.b; 


Table  to:  Summary  of  Implemented  Commands 


f-i.  F0RTRAN--8U 


I.  background 


The  FORTRAN  implementation  is  written  in  Microsot t  FGRTRAN-80 
Ea] .  This  FORTRAN  dialect  has  AMS 1 1  FORTRAN  10  as  a  subset . 
i Unusual  ex  tent ions  include  the  anility  to  give  identical  names 
to  variables,  subroutines  and  COMMON  areas. /  The  compiler  and 
l inner  are  both  fairly  small.  in  fact  this  is  tne  only  1 anquaqe 
that  we  can  use  on  our  Meath  •'  ten  l  th  ZifV  ini.  cro—comouter  with 
single  densitv  G  i/4"  disks.  flie  language  has  some  unnovi  nq 
i  di  osvnor  aci  es.  The  more  impor  taut  of  these  are  men  cloned  in 

■ 1  -■  <  t.  |.  <  _.<i  i  t. . 
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The  N-Server  Queuing  System 


To  illustrate  the  FORTRAN  implementation  we  present  in  Progr 
the  FORTRAN  version  o+  the  N-server  queuing  system  example. 


C  !  SIMULATION  MODEL  OF  SIMPLE  8UEUIN6  SYSTEM  ! 

C  • . - . ♦ 

cowan  / data/nser v, tarr i v, tserv , lbin 
cotton  /CLOCK/ tnos. tend 
cowon  /COLCT/nc  (10)  ,other  (40) 
cowon  /LIST/nl ists, ievset ,  lghead, al i st  (4, 
cowon  /SEED/iseed 
cowon  /TRACE/ 1  trace 
C  VARIABLES 


subroutine  ar r vl 


nserv  -  nueber  of  servers 
tarriv  =  eean  inter  arrival  tile 
tqerv  =  lean  service  tiie 


C  NODELL I N6  UNITS 


C  place  in  service  if  server  is  available 
diiension  »ttrib(4) 
cowon/data/nserv,tarriv,tserv,ibin 
400/ ,  iptr  <400/  cowon/CLOCK/  tnox 

if  (NSlZE(l).ge. nserv)  go  to  1000 

call  servettnw) 

return 

C  place  in  queue 

1000  attrib  U)  =  Tnoi 
attrib<2)  *  Tnoi 
call  INSERT <2,attnb> 

C  schedule  next  arrival 
return 
end 


Event (1)  =  Custoaer  arrival  (recurrent 
(2)  =  End  of  service  (triggered 
Colct(l)  -  Wait  tiie  in  queue 
(2)  -  Halt  tiies  m  systei 

call  INIT 
tarriv  =  0.5 
TFin  =  100.0 
nserv  =  2 
tserv  =  0.8 
call  RECUR (1, tarriv) 
call  SCHEDl3,TFini 
1000  call  NEXTEV (icode) 

if (icode.eq. 1)  call  arrvl 
if ucode.eq.2)  call  depart 
if (icode. ne. 3)  goto  1000 
call  REPORT 
stop 
end 


subroutine  serveitentry) 

diiension  attrib (4) 

cowon  /data/nserv, tarriv, tserv, lbi n 

cowon  /CLQCK/tno* 

twit=tno»-tentry 

call  CQLCT 1 1, twait) 

ts=£RLAN8 itserv, 3) 

attrib(l)=ts*tnoit 

call  INSERT (1, attrib) 

call  SCHED(2,ts) 

return 

end 

subroutine  depart 
diiension  attrib 

cowon  /data/nserv, tarriv, tserv, i bin 
cowon  /CLOCK/tnoM 

server  finishing  first  is  first  in  set 
call  REMOVED, attrib) 
tsys-tnoH-attribi2) 
call  C0LCT (2,tsvsi 
inN51ZE(2).le.0)  return 
call  REM0VE12, attrib) 
call  serveiattnbil)) 
return 
end 


Program 


FORTRAN 


non  ot  N— Server  Queuing  System 


The  Data  Base  System 


Our  FORTRAN— 80  implementation  is  particularly  weak  in  the  set 
management  area.  Since  FORTRAN  IV  does  not  support  records  ana 
dynamic  memory  management,  it  was  necessary  to  create  a  iarue  i wo 
dimensional  array,  each  row  of  which  would  be  available  tor 
poss  i  b  t  e  ei  t.her  as  an  event  or  as  an  enti  tv  recor  d, 

i There*  ore  both  record  types  are  ot  the  same  size.  >  When  not  in 
use.,  these  rows  are  strung  together  into  a  garbage  list  from 
wfii  ,„li  r  ec  or  ds  ar  e  drawn  a  s  needed,  and  to  whic.h  recor  us  ar  e 
r  etui  netl  win  n  no  lonuer  in  use.  live  fol  lowing  subroutines  anu 
tunc  Lions  were  de--  i:  i  <  'pec!  tor  tlos  pm  pose: 
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SubroutineYFunctioni  Purpose 

INIT 

!  Creates  the  record  pool  and  links  all 
!  records  into  the  garbage  l’st. 

NENRECidueay) 

!  Reaoves  next  available  record  fro* 

!  the  garbage  list  and  returns  its  index 

:  LNKREC ( i set, l reel 

!  Links  record  ’irec’  into  set  nuaber  ’ i set ’ 

!  LNKOUT ( i set «i post 

!  Reaoves  the  record  in  logical  position 
!  ’ipos’  froa  set  'iset',  returns  its  index 

Table  7:  List  Processing  Routines  tor  FORTRAN  Implementation. 


The  records  used  tor  event  scheduling  and  set  management  are  all 
stored  in  the  array  LIST  in  the  common  area  /LIST/  (note  the  non 
standard  naming  convention).  Their  content  is  described  in  Figure 
6.  Note  that  a  considerable  amount  of  memory  space  is  wasted  due 
to  the  restriction  that  all  records  be  ot  the  same  size. 

♦ - * - ♦ - ♦ 

:  :  HEADER  RECORDS  i  ENTITY  RECORDS  ! 

[Field  ♦ - ♦ . ♦ . ♦ - ♦ 

!  nuaberiUSER  DEF-  ! EVENT  IUSER  I  EVENT  I 

♦-.♦..-♦IKED  SET  I  NOTICE  I0EFINED  INDUCE  I 

iintlrei!  HEADER  I  HEADER  [ENTITY  I  I 

I  Number  of  iNuaber  of  I  !Ti«e  I 

I  1  I  ! i nser t ions  I  insertions  I  lot  I 

♦ — ♦  l  ♦ - ♦ - ♦  ottribU)  levent  I 

(Current  I  Current  !  !  I 

2  I  Isize  of  isize  of  I  set  ranked!  I 

— ♦ — t - ♦ - ♦ - ♦ - ♦ 

!Ti«e  spent!  I  I  Event  I 

13  1  !  in  set  by  i  !  I  Code  I 

2  [entities  I  not  used  I  attrib(2)r ♦ 

Ino  lonqer  I  I  II 

.'in  set  I  !  ! 

-*■ - ♦ - 1 - ♦ - ♦ 

ITite  of  I  I  II 

.’last  .'  II 

♦ — ♦  3  Ichange  in  !  not  used  I  attr ib (3) Inot  used! 

[state  of  :  :  :  i 

[set  [ 

-t - ♦ - 1 - ♦ - 1 

i  not  used!  !  [Avg  Intel 

17!!  I  !  Irval  for! 

4  ♦ . !  not  used  !  attriblf) Irecur’nt! 

!  !  !  [events,  ! 

8  !  !  not  used  !  !  lor  zero  ! 

— ♦ — t - 1 - ♦ - ♦ - ♦ 


Figure  6:  Content  of  Records  in  FORTRAN— 80  Implementation 

For  convenience  we  store  4  byte  reals  and  2  byte  integers  in  the 
same  array.  The  following  equivalence  statements  in  FORTRAN  are 
used  for  this  purpose: 


REALM  ALIST (4, 100) 

INTE8ERI2  LIST (8, 100> 

EQUIVALENCE  (  ALISTIl.ll.LISTU.il  I 
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All  set  related  data  is  stored  in  the  COMMON  area  /LIST/. 
Headers,  event  records,  and  entity  records  are  stored  in  the 
array  ALIST;  pointers  are  stored  in  the  array  IPTR.  In  Figure  7 
we  illustrate  how  the  event  list  in  Figures  4  and  5  might  be 
stored  in  this  structure: 


Gar  Put  set  set 
bag  ure  1  2 


* — . ♦- 

:  i  : 

1  i 

2  ! 

3  ! 

4 

l 

- 

5  ! 

6  : 

7  ! 

: : 

— f 

99! 

: 

o  : 

-  : 

o  : 

0 

< 

» 

1 

I 

1 

> 

99! 

t  : 

:  list(2,i)i 

3  ; 

- 

1  _  1 

1  1 

t 

1 

vJi 3** 

i 

i 

!  list (3, i 1 i 

- 

1 

1 

2  : 

3  ! 

i  i 

!  list (4,1)1 

- 

1 

1 

i 

"  i 

_  i 

!»list(3,i) ! 

i  l 

t  i 

t 

t 

i 

i 

i 

i 

i 

i 

» 

- 

» 

l 

1 

1 

i 

1 

1 

1 

i 

i 

t 

1 

l 

1 

t 

i 

i 

lilist(4,i)i 

i  i 

i 

i 

i 

i 

i 

i 

i 

• 

• 

- 

1 

1 

1 

( 

0.00! 

I 

0.00! 

1 

I 

3.00! 

I 

I 

l 

1 

► 

i 

> 

« 

:  iptr(i)  : 

+ - f- 

8  { 

7  i 
— 

3  J 
— +■ 

4 

1 

6  ! 

2  ! 

5  ! 

3  S 
— 

1  ! 
— ♦ 

record  lumber 


Figure  7:  FORTRAN  Representation  of  Event  List  in  Figure  6. 


4.  Some  Notes  on  Program  Development 

In  developing  the  target  language  we  took  special  care  to 
separate  information  that  the  modeller  needs  from  information 
that  she  does  not  need.  This  design  goal  was  only  partially  met 
in  our  FORTRAN  implementation.  Specifically,  we  were  unable  to 
hide  the  simulation  data  base  from  the  user,  as  she  is  required 
to  include  data  base  related  COMMON  statements  in  almost  all  her 
subroutines.  Not  only  does  this  reduce  program  readability,  it 
introduces  a  significant  source  of  errors  as  programmers 
frequently  fail  to  place  identical  COMMON  statements  in  all 
functions  and  subroutines. 

Another  goal  of  the  target  language  was  to  facilitate  the 
development  of  models  that  were  self  documenting  and  easy  to 
read.  Again ,  our  FORTRAN  implementation  was  only  partially 
successful.  With  short  variable  names,  no  compile  time  constants 
and  no  bleed  structure,  it  is  extremel v  difficult  to  write 
readable  complex  programs  in  FORTRAN. 
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B.  PASCAL /MT  + 


1.  Background 

Pascal /MT-*-  it  a  CP/M  based  true  compiler  with  useful  extensions 
such  as  overlays,  strings  and  separately  compiled  modules.  This 
compiler  is  substantially  larger  and  slower  than  our  FORTRAN 
compiler,  and  we  were  not  able  to  use  it  on  our  Heath /Zenith  ZS9 
computer  with  single  density  5  1/4"  drives.  Instead,  we  used  a 
larger  system  (Sierra  Data  Systems;  with  8"  drives. 

2.  The  N-server  queuing  system 


Our  Pascal  implementation  of  the  N-server  queuing  model  is 
presented  in  Program  3. 


program  q  u  nput , output ; ; 

(♦Iueclns) 

{* 1  Dec  1 1 > 

(Start  of  user  written  model} 

( . - . } 

procedure  Simulate; 


var 

( - variables  used  in  simulation  »ooel - } 

EndTiee  i  Real; 

Eos! lie  :  Real; 

NeanlnterArnvalTiae  i  real; 

HeanServTiae  :  Real; 

Servers  :  Integer; 

( - } 

procedure  arrival; 

( . > 

begin 

attributellh'^TNow; 
it  SizeQf  (BemgServedSet)  <  Servers 
then  StartService 
else  InsertlntolHaitingUneSet); 
end; 

{ . - . . } 

procedure  StartService; 


var 

ServiceTiae  :  real; 

TimeNaited  :  real; 
begin 

ti merited  TNo*  -  ate£21; 
if  i  Tiaetfaited  <>  0.0 
Collect  t  JJiaebaited 
ServiceTiae:=  ErlangiHean5ervTime,3)  ; 
Attributellh-ServiceTiae  *  TNow; 
Insert  Into i BeinqSet vedSet); 

Scbedul e i Depar  t ureEven t , Ser  vi ceJ l  me; ; 
end; 


(- — . } 

procedure  Depart 

( . - . i 


var 

TieelnSvstea  :  real; 


begin 

RemoveFroalBeingServedSeti; 

TiaelnSystea  :=  Tnow  -  Attribute^]; 
Collect  i  1,  TiaelnSystea  i; 

It  SizeOf (Mai t ' ngLi neSet >  >  0  then  begin 
ReaoveFroa  (KaitingLineSeti ; 
StartService; 
end; 
end; 


begin  (Simulate} 

EndTiae  i=  10; 

HeanlnterArnvalTime  :s  0.5; 

HeanServTiae  :=  0,4; 

Servers  :=  1; 

Initia’ice; 

Recurrent  (ArnvalEvent,  Hean Inter Arr l val T i aei ; 
Schedule  tlastEvent.  EndTiae;; 

repeat 
wx  tEvent ) 

case  CurrentEvent  ot 

ArnvalEvent  :  arrival; 

DepartureEvent  ;  depart; 
end; 

until  (CurrentEvent  =  LastEventi; 

Report; 

Histogram; 

end;  (Si *ul ate ; 

{  end  ot  user  model  < 

begin 

Simulate; 

end. 


F'r.jqr  am  J.:  h'.-tscui  hi  I  vers  ion  at  the  ■■}  her  ...  i  gu»  <u  uo  mod*.-! 
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3.  Data  base  Design 

The  desiqn  of  the  database  capitalizes  on  the  tact  that  Pascal  is 
able  to  create  and  dispose  of  records  dynamically  as  needed 
without  any  cumbersome  user-defined  garbage  list.  (The  price  we 
pay  for  this  is  that  we  no  longer  know  in  advance  the  exact 
location  of  any  specific  record.  Instead,  we  use  pointer 
variables  to  lead  us  indirectly  to  the  desired  information.; 

Event  notices  are  represented  as  records  with  the  following 
f  or mat : 

Eventnotice  :  record 
Tiee  :  real; 

Type  :  integer; 

Next  :  A  Eventnotice 

end; 

Entities  are  represented  as  records  with  an  essentially  similar 
format. . 


(Tiee  of  event) 

(Type  of  event) 

(Pointer  to  another  event  notice) 


Unlike  our  FORTRAN  implementation  in  which  all  records  were 
required  to  be  of  the  same  size,  our  Pascal  implementation  allows 
records  of  different  sizes.  We  exploit  this  flexibility  by  making 
our  header  records  larger  than  our  entity  records  so  that 
additional  performance  information  can  be  collected  for  each  set. 

The  structure  of  the  resulting  database  is  presented  in  Figure  8: 

Perianent  Records  Records  Dynamically  Created  and  Disposed  as  Needed 


Event  Header  Event  notices 

♦ - *  * - 1 - ♦  ♦ - v - ♦ 

'  pointer  ' . ;!  Data  !  pointer! - > . . >:  Data  !  pointer!  — "! 

- ,  ♦ — — — ♦- - 1  t - ♦ - + 


f - ♦ 

1  Array  ! - 

> - * 

1  of  . > 

f - ♦ 

•  pointers  1 - ; 

♦  - ♦ 

i  i 


Set  Header (si 

♦ - ♦ 

!  Data  ! 

!  collected  1 

!  on  set  1 

♦ - ♦ 

!  entity  pointer  !■ 

t - ♦ 


Collect  Pointeris; 

f - 1 

1  Array  ot  1 . 

* - ♦ 

1  pointers  * . 

t - 1 


♦ 


Collected 

data 


♦ 


♦ 


Entity  Records 


♦ - 1 - ♦ 

r.  Attributes  1  pointer* 

♦ - ♦ - ♦ 

i 

i 

♦ - - — —t 

y 

♦- - - - ♦ - ♦ 

1  Attributes  1  oointer1 
* - ♦ - 1 

IT- . » 


i  i  out  >■  o  :  .'-.i  u  c  Ui  i  ►  u  <  1 1  nr‘  Pascal  L*a  t  alias* 
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4.  Some  Notes  on  Program  Development 


Pascal  is  a  strongly  typed  language  ri.e.  all  variables  must  be 
defined  before  they  are  used).  Students  trained  in  FORTRAN  find 
this  to  be  annoying  at  first.  However,  there  is  no  doubt  that 
this  feature  substantially  reduces  the  length  of  time  it  takes  to 
develop  a  working  program. 

Since  Pascal  does  not  support  static  variables,  it  was  necessarv 
to  give  a  global  scope  to  all  variables  used  by  our  language. 
This  was  done  by  declaring  these  variables  in  the  main  program. 
Fortunately,  Pascal /MT+  provides  an  "include"  macro  instruction 
whereby  the  name  of  a  file  containing  declarations  can  be  used  in 
lieu  of  the  declarations  themselves.  This  reduces  user  effort  arid 
increases  readability. 

A  separate  procedure  "Simulate"  is  used  to  contain  the  user 
written  model.  This  causes  a  clear  separation  between  user 
written  code  and  data  and  global  data  used  by  the  1 anguage  itself. 


C.  ADA/ JANUS 
1.  Background 

Ada  15  a  large  and  complex  language  that  appears  -from  it5 
specifications  to  be  extremely  well  suited  for  the  design  goals 
of  this  project.  A  nice  introduction  to  Ada  is  given  in  C13. 
Bryant  C33  discusses  simulation  programming  in  Ada. 

To  our  knowledge  no  complete  implementation  of  Ada  is  available 
for  CP/M  based  micro-computers.  However  several  "subsets"  are 
available.  We  acquired  two  versions  for  this  study.  Unf or tunatel y 
neither  of  these  provide  all  the  features  required  for  a 
simulation  language.  Ada/Super sof t  1113  does  not  support  records 
and  dynamic  memory  management  (not  to  mention  packages  and 
separate  compilation  >.  Ada/Janus  C103  provides  these  features, 
but  does  not  (yet)  support  real  variables.  Both  vendors  promise 
to  implement  the  entire  Ada  languages  in  later  versions. 

In  order  to  investigate  the  powers  of  Ada,  we  chose  to  use 
Ada/Janus,  as  we  felt  that  the  omission  of  real  variables  is 
outweighed  by  the  presence  of  records,  memory  management  and 
separately  compiled  packages.  (We  understand  that  real  variables 
will  be  provided  “soon”.) 

At  a  first  glance  one  may  notice  that  Ada  is  very  similar  to 
Pascal.  However,  Ada  has  more  to  offer  in  elegance  and 
proqram  structure.  Ada  boasts  of  a  high  level  of  data 
abstraction.  By  this  we  mean  that  it  is  possible  in  ADA  to  build 
modules  which  are  entirely  independent  of  each  other,  and  which 
can  be  used  without  any  knowledge  of  the  internal  design  of  the 
module.  This  is  one  of  the  most  advanced  features  of  ADA. 


These  modu 
constructs 
(opt i onal > 
resources 


les  are  called  "Packages".  Packages  are  the  main 
of  an  ADA  program.  Each  package  has  a  declaration  part 
and  a  body  part.  The  declaration  part  represents  the 
(data  structures,  types  and  the  names  of  the 


procedures/f unctions)  available  to  the  user.  The  package  bodv 
implements  these  resources.  The  package  body  may  contain 
implementation-dependent  resources  hidden  from  the  user.  Packages 
containing  only  type  and  object  declarations  do  not  need  a  body. 
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The  N-server  queueing  system 


The  Ada  implementation  of  the  N-server  queueing  model  is  as 
toll ows: 


Kith  5, Events,  Sets,  Datacol;  - 

procedure  arrive  is 

package  body  Siaulate  is  - 

use  s.  Events,  Sets,  Datacol;  begin 

attributed)  s*  Tiee  New; 

Arrival.Event  :  constant  t-  ’a’;  attnbute<2)  :=  Tiee'Nou: 

Departure  Event  i  constant  1=  !b’i  if  Size  of (Beingservedset)  i  Nuaber  of  Servers 

Last.Event  :  constant  ;=  ’l’j  then  Start. Service: 

else  Insert  Into  (KaitinglmeSeti; 
DeingservedSet  :  constant  :=  1;  end  it; 

NaitinglineSet  :  constant  :=  2;  end; 


Current  Event  :  character; 

End.Tiae  :  integer  :=  32000; 

Hean.Inter.Arrival.Tiee  :  integer  8: 
Hean^Service.Tiae  ’  :  integer  ;  =  10; 

Nuabir  of. Servers  :  integer  :•  3; 


procedure  Start. Service  is 


Service  Tiae  :  integer; 

Tiae.Haited  :  integer; 

begin 

fiae  baited  s*  Tiae  Non  -  Attribute  (2); 
if  Tiae  Halted  >  0  then 
Collect  U.Tiae  Halted); 
end  if; 

Service  Tiae  :=  fiandoa  (Mean  Service  Tiae); 
Attributed)  s*  Service  Tiae'*  Tiae.douj 
Insert  Into  (BeingServeBSet); 

Schedule  (Departure  Event,  Service  Tiae); 
end; 


procedure  depart  is 


Tiae.Spent.in.Systea  :  integer; 
begin 

Reaove.Froa(BeingservedSet): 

Tiae  Spent  in  Systea  Tiat  Non  -  Attributed 2; ; 
Collect  t  2,  Tiae  Spent  in  Systea  i; 
if  Size.of  (HaitihguneSetT  ;  0  then 
Reaove  Froa  (HaitingLineSet); 

Start  5ervice; 
end  if; 
end; 


begin 

Initialize  Event  List; 

Imtialize'Sets;’ 

Initial ize~0ata_Col lection; 
recurrent(«rrival.Event,  Hean  Inter  Arrival  Tiae); 
Schedule  (Last. Event,  End.Tiaei; 

loop 

Next  Event  (Current  Event); 

if  (Current  EvenHLast  Event)  or  else  (Tiae  Non>327m)i 
then  ex  ft; 

el  si f  Current  Event  -  Arrival  Event  then  arrive: 
else  depart; 
end  if; 
end  loop; 


Set  Report; 
Collect. Report; 


end  siaulate; 


Program  4;  hUA/ Janus  N-Ser  ver  Queue  .mg  Mode  t 


.1 .  L) a  tat) a <5 e  Dt;.  i. , j r , 

'he  dt-i  a  structure  used  in  flit  huh  ■  ,1  <:m  m-  i  mu  i  ement.  at.  i  on  is 

identical  to  that  of  the  Pa  Be  a  l  'If  v-  i  mp  !  e*nei  >t  a- .  mii.  Mewe-er  ,  ,  n 

this  x  ,i,(.  *  1  emen  t .at  i  on  these  strur  I  i  ir  ,  >?-  are  m. ,  i  n  t.  -  <  n  md  i  n  In  ter  t-iif. 
|-acl  .vqt'Sj  i  .  e.  tii*?  jet  managemei  ,i.  pa*:  i  aue  a  • ,  i  •  i  ctes  and  mai  nl«i  n& 
r.  h  *  •  ♦/ 1  header  r  ei  ot  dr-  and  the  ^nt  i  I  v  J  t  ■  - :  In,  •  .  t  f,t  h  eU  u  1  i  rig 

f  rtUtT  i  I  "•  l  t.  J  c*  f  t  r?l  •(.!  1  I  f  1  <  I  f  *  *'  t  *  I*  *  ■  e  j  ,  !  i  <  •-%  t  ,  f  ■»  (  r  „ 

The  scone  <  d  the  variable?  et  .  •  1  ..  *  aue  1  ■:  <  >n  I  %•  witnin 
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that  package  itself.  However,  a  package  can  be  made  visible  to 
another  at  compile  time  with  the  use  of  a  "WITH'  clause.  fhis 
means  that  one  package  can  use  and  alter  another's  data,  and 
local  variables  of  a  package  will  remain  in  existence  between 
calls  to  the  package. 

4.  Notes  on  F-'roqram  Development 

In  our  ADA/Janus  implementation  we  found  it  easy  to  develop  and 
hide  trom  the  user  separately  compiled  modules  each  containing 
parts  of  the  entire  simulation  database  and  list  processing 
routines.  This  was  one  of  our  major  design  goals  which  we  were 
able  to  achieve  only  in  this  implementation.  Another  goal  we 
achieved  here  was  total  freedom  in  the  length  of  variable  names. 
This  also  contributed  to  the  code  being  extremely  self- 
document i nq . 

Ada's  modules  are  useful  tools  for  providing  the  programmer  with 
modular  computational  ease.  They  allow  algorithms  /operations  to 
be  independently  developed  and  used  as  components  of  larger 
programs.  This  facilitates  top-down  program  development  which  is 
only  possible  with  a  language  whose  program  units  have  a  well 
defined  user  interface  that  hides  the  implementation  details.  The 
onlv  global  variables  in  our  1  mpl  ementat.  1  on  were  time  "Time"  and 
"Trace" . 

The  packages  we  developed  in  addition  to  the  main  program  were: 

Event  scheduling  package  (EVENTS); 

-  contains  in  its  declaration  part  the  event  record 
type,  event  list,  etc.  It.  contains  in  its  body  tne 

procedures  for  event  scheduling  given  in  Table  3.  Hie 
random  number  generator  also  resides  in  this  package 
body  since  it  was  used  for  the  generation  of  events. 

Set  management  (SETS): 

-  contains  in  its  declaration  the  structure  ot  the  set 
header  records,  entity  records,  etc.,  and  m  its  Dodv 

the  procedures  outlined  in  Table  4. 

Data  Collection  iDATACOL): 

-  contains  in  its  declaration  the  data  structures  o*  the 
various  data  collecting  ar>  avs,  and  its  body  '.an  be 
seen  in  till. 

A  minor  drawback  of  this  implementation  is  t.Aat  the  tilt 
containing  the  package  had  to  have  the  same  name  as  the  pad  age. 
fhi  s  rciti  irked  the  package  name  to  ri  character  s.  Vendors  ot 
tida  .i  am  is  hope  to  have  tins  restriction  removed  soon. 
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Given  the  many  different  schools  of  thought  in  all  areas  ot 
applied  simulation  analysis,  we  do  not  hope  to  be  able  to  provide 
definitive  answers  to  the  question  of  which  language  is  "best" 
for  simulation.  Instead,  we  restrict  our  evaluation  to  a 
comparative  study  our  three  micro-computer  bases  language 
implementations.  The  results  of  this  evaluation  are  discussed  in 
the  following  sections,  ana  they  are  summarized  in  Table  b. 


DESIGN  OBJECTIVE 


MODELLING  CAPABILITIES  (general  purpose) 


-  Discrete  event  scheduling  using  user  written  event  routines 

-  Autoaatic  scheduling  o f  recurrent  events 

-  Floating  point  clock 

-  Set  KMelling  capabilities  with  autoaatic  data  collection 

-  Service  routines  f or  collection  and  display  of  user 
specified  data. 

-  Keyboard  control  of  running  eodels. 

-  Five  coeeon  randoe  nueber  generators 


i  Objective  eet 

? 

i  Ada/Janus  ! 

FORTRAN-80 

Pascal/HT* 

I  yes  I 

yes 

yes 

i  yes  1 

yes 

yes 

i  no  ! 

yes 

no 

i  yes  ! 

yes 

yes 

(only  integers) 

yes 

yes 

!  yes  1 

yes 

yes 

i only  integers! 

yes 

yes 

USER  INTERFACE 


(user  friendly) 


-  The  user  should  not  need  to  understand  the  design  of  the 
siaulation  data  base. 

-  The  user  should  not  be  able  to  cause  run  tiae  errors  in 

the  siaulation  package  (for  esaaple  by  reaoving  a  non 
existing  entity). 

-  The  resulting  code  should  be  a  seif-docuaented  aodel 

-  Host  language  should  be  designed  to  facilitate  prograa  debugging 

-  Model  verification  should  be  facilitated  by  extensive  error 
checking  and  an  interactively  controlled  trace  feature. 


RESOURCE  CONSIDERATIONS  (run  on  8  bit  aicros) 


-  The  language  should  be  saall  enough  to  allow  rooa  for 
reasonably  coaplex  aodels  on  a  64k  byte  aicro-coaputer. 

-  Tiae  required  to  coapile  and  link  a  aodel  should  be 
sufficiently  saall  to  facilitate  interactive  aodel  developaent 
on  a  desk  top  coaputer. 

-  Tiae  to  execute  a  aodel  should  not  be  excessive. 


Table  3:  Evaluation  summary. 


yes 

perhaps 

perhaps 


no 

soaewhat 


perhaps 


pernaps 


A.  Modelling  capabilities. 

With  the  exception  of  Ada/ Janus'  absence  of  t  1  oat  i  mi  pomi 
variables,  we  were  able  to  implement  the  entire  simulation  system 
in  each  programming  language.  However,  the  FuPTRhW  implement  a I  n  .n 
was  less  flexible  than  the  other  implementations  **:•>  we  wer  *• 
required  to  specify  at  compile  Lime1  I  he  me  ,  i  mum  dimeie  mn  <n  u  I 
data  collection  arid  set  management  artuvs. 

Each  1  anquaqe  provided  the  necessarv  oper  uting  svseem  inter  f  or 
routines  to  facilitate  real  unit  inter  r  upt  ion  <<♦  a  i  nniuou 
si  mu  1  ni  ii  hi  model  . 
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B.  User  interface. 


Perhaps  the  most  significant  differences  in  our  i  mpl  enientat  i  ons 
are  in  the  data  base  area,  Our  primary  goal  of  hiding  the  data¬ 
base  from  the  user  was  only  fully  met  in  Ada/ Janus  where  the  use 
ot  separ  ate  pact  ages  completely  removed  the  entire  simulation 
database  from  the  scope  ot  the  user.  We  were  almost  successful 
in  hiding  the  database  in  Pascal /I1T  +  .  By  nesting  the  user 
programs  inside  the  simulation  system,  we  relieved  the  user  from 
having  to  define  the  database.  However  the  entire  database  is 
still  within  her  scope.  In  FORTRAN— 80  it  was  not  possible  to  hide 
the  database  at  all. 

The  related  goal  of  preventing  the  user  from  accidentally 
changing  the  content  of  the  database  was  met  in  Ada/Janus  and 
Pascal.  It  was  only  partially  met  in  FORTRAN— 80.  lErrors  in  user 
written  COMMON  statements  might  result  in  a  corrupted  data  base.) 

With  respect  to  the  goal  that  t. he  languages  result  in  readable 
simulation  models,  we  would  judge  that  this  goal  was  reached  for 
Ada/Janus  and,  to  a  slightly  lesser  degree  by  Pascal /MT-f.  The 
goal  was  not  reached  for  the  FORTRAN-80  implementation.  (A  seen 
in  Program  2,  even  a  simple,  well  written  FORTRAN-80  program  is 
difficult  to  read.)  Tnese  differences  in  readability  were  caused 
b>  several  factors.  We  believe  the  most  important  of  these  to  be: 

1.  The  ability  to  hide  confusing  details 

2.  The  use  of  long  variable  names 

3.  Block  structured  programming  (begin-end,  l f -then-el se/ 

4„  Use  of  named  constants. 

fj .  Use  of  records. 

We  were  able  to  implement  reasonable  error  checking  and  trace 
features  in  all  systems.  Modelling  errors  should  therefore  be 
equally  easy  to  find  in  each  implementation.  This  is  not  so,  for 
coding  mistakes.  Pascal /MT  +  and  Ada/Janus  are  both  strongly  typed 
languages.  This  means  that  each  variable  must  be  explicitly 
defined  before  it  is  used.  While  this  is  annoying  to  a  FORTRAN 
trained  pr ogr ammer .  there  is  no  doubt  in  our  opinion  that  this  is 
a  valuable  feature  that  helps  eliminate  coding  errors  and  reduce 
the  total  Lime  requii  k)  to  develop  a  work  mg  program. 

FUR  TRAN- 8e  s  error  messages  were  confusing  and  often  misleading, 
in  addition,  the  FOR  I'R  AN  -80  eompiier  proved  to  nave  a  few  strange 
dug s .  f oi  example  blank  lines  at  some  times  cause  unpredictable 
let  It  tel  us’  errors,  at  other  times  they  cere  accept  eg 

without  i.  imp. I  di  lit.  ..  More  ser  iou-lv,  there  appears  to  be  a  bug  in 
tne  Wr.iv  arguments  ..re  passed  to  and  fi  em  subroutines.  Passing  of 
i.  <<nc  taut  ■  ■•jii.tr  i.  i  in  ■-  caused  unpredictable  values  to  be  returned. 

I  mat  i  V  I  he  '  I.  Ip  I  In  ill  do  manual  ,.  s  about  as  r  eal.Ja.Lle  as  the  old  IBM 
f  I  )  I  ■*'  i  !  AmN  i  i  *  I  1 1  « <  I  4  1 
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Pascal  /  M  l‘  +-  it:  much  easier  to  debug  and  has  much  tie  t  ter  compiler 
error  messages.  The  manual  is  also  much  bei ter.  'However  we  feel 
that  the  inclusion  of  more  complete  e  amp  lea  would  he-  helpful*. 
Ada/  J  anus  has  al  1  the  advantages  over  FORTRAN  that  r'ascai  has. 
and  in  addition  its  manual  is  quite  readable. 

C.  Rebourte  Requirements 

1.  Memory  Requirement 

As  presented  in  Table  9  significant  differences  in  storaqe 
requirements  were  observed: 

I  !  Adi/Janus  i  FORTRAN-80  !  Pascal /NT *  ; 


!  Size  of  File  containing  1 

1  Executable  Model 

26k  i 

44k 

i  27k 

I 

» 

1  Maxima  Queue  size  for  1 

2035  : 

1562 

!  1007 

1 

I  N  Server  aodel  !  !  !  ; 

Table  9:  A  Comparison  of  Memory  Requirements 

It  is  seen  that  a  FORTRAN— 80  model  requires  substantially  more 
disk  space  than  the  other  languages.  While  this  in  itself  is  not 
a  serious  problem,  it  is  a  symptom  of  a  serious  drawback  with  the 
FuRTRAN-80  system;  namely  that  the  linker  creates  a  file  that 
contains  both  the  executable  code  and  the  data  storage  area. 
Since  the  linker  and  this  file  must  be  memory  resident  at  the 
same  time,  the  effective  memory  space  available  to  a  program  is 
reduced.  <  The  other  compilers  are  able  to  store  data  in  the  area 
used  by  the  linker,  FORTRAN  is  not). 

In  order  to  get  a  measure  of  the  relative  sire  of  problems  that 
could  be  modelled  with  our  three  i rnp 1 ement at l uns ,  we  measured  the 
largest  queue  sizes  that  could  be  accomodated  without  mentor v 
o v  er  r  1  ow . 

This  read  l  is  also  presented  m  the  above  table,  it  js  seen  that 
Pascal  /  NT  i-  could  handle  about  1000  customers  at  one  time  while 
FORTRAN  could  handle  1 5o0  and  Ada/ Janus  about  2000 .  Since  Fortran 
is  a  much  small  oi  1  enquaqe  titan  Pascal  we  were  not  supr  l  sed  to 
\:.-ee  that  t  i  left  mot  e  space  for  data.  Note  however  that  whenever 
we  changed  dimensions  in  our  r URTRhN  database  we  had  to  recompile 
and  link  the  entire  program.  This  was  not  necessui  v  in  Pascal  and 
uDa/ Janm  .  Ine  fact  that  r. cia/ Janus  left  over,  mor  e  space  than 
Pasca  1  w..e»  if  ii  t  f  sur  pi  i  sing  nul  l  1  we  r  e«.<  l  a  *  ed  t  h a t  t  he  records 

used  4  o  r  eur  eserit  event  not  ices  and  set  members  in  Ada  nr  fc 
Biiict  l  lor  i  two  h  >,  to  l  nt  eqer  u  were  ub  ed  t  r-:T  ea.1  ot  v  he  four  b  v  t.  e 

real  v,ir  laoles  hied  in  the  *  d  her  I  uiiquaqes.  A*  I  mitii.q  for  this 

fur.  t.  .  I  hi  mid.'  %  i  anus  model  is  hut  as  Hit  nur  v'  crl  i  •;  t  el  it  ac  the 

F  1 1, .  1  a  t  j  i  •  .it  nt*  I  ‘li  •  1  i  gitt  l  v  m<  ‘i  *  ■  e  t  i  t  .  i  t  1 1 1  i  l.<.u  f  lie  l-asi.al  .  M  f  -i 

lit*  i  • 
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Speed 


In  Table  10  we  present  the  results  ot  tour  different  timinq 
evaluations.  lA  fifth  measure  "time  to  simulate  1000  departures" 
vi elded  meaningless  results  due  to  Ada/ Janus’  absence  of  floating 
point  variables). 


Ada/Janus  I  F0RTMM-80  ;  Pascal 


1  Tue  to  compile  Sieuiat-: 

1  ion  library  ! 

795  sec  ! 

a 

t 

75 

sec  1 

62  sec 

1  Ti*e  to  coepile  todel  ! 

lib  sec  1 

16 

sec  1 

62  sec 

I  Tiae  to  link  proqraa  1 

53  sec  1 

88 

sec  i 

5t>  'ec 

1  Tiae  to  coipile  and  link! 

169  sec  i 

104 

sec  ! 

108  sec 

Table  10:  A  Comparison  of  Resource  Requirements 


It  is  seen  that  the  time  to  compile  the*  simulation  system  itself 
is  an  order  of  magnitude  slower  with  Ada/ Janus  than  with  the 
other  systems.  This  is  not  it  serious  problem  as  the  user  would 
not  be  expected  to  recompile  thi s  system  very  often.  Turning  now 
to  the  Lime  required  to  compile  the  model  and  to  link  it  to  the 
rest  of  the  simulation  system,  we  see  that  FORTRAN  has  the 
fastest,  compiler  and  tire  slowest  linker.  Combining  the  times  tor 
cumplilinq  and  linking,  we  see  that  Pascal /tlTt  ,  and  FORT  RoN-  do 
are  equally  fast  (or  slow?)  and  that  Ada/ Janus  is  about  Sue 
s 1 ower . 
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Each  of  our  language  implementations.  excel  in  some  areas, 
t uF< TRAN-80  is  -fast  and  memory  efficient,  Rascal/ I’ll +■  is  ucer 
friendly  and  reasonably  -fast,  and,  Ada/ Janus  has  an  exceptional  t  v 
nice  structure  leadinq  to  programs  that  are  quite  readable  arid 
easv  to  work  with. 

On  the  other  hand  FORTRAN-80  is  difficult  to  debug,  Pascal  /  til  +  as 
not  very  memory  efficient  ,  and  Ada  is  slow  and  does  not  at  this 
time  support  real  variables. 

Given  the  absence  ot  real  variables  1 n  the  present  implementation 
of  Ada/Janus,  we  conclude  that  of  the  three  languages,  Pascal /HI + 
is  the  one  best  suited  tor  mi c rocomputer  based  simulation 
analysis  at  this  time.  However  we  were  extremely  impressed  with 
the  structure  of  Ada/Janus,  and.  wnen  floating  point  variables 
become  available,  we  believe  Ada/Janus  would  be  the  language 
worth  considering. 

As  a  final,  consi  der  at  l  on ,  we  note  tnat  the  close  to  two  minutes 
required  to  compile  and  1  i  rd  our  simulation  models  felt  quite 
excessive.  since  most,  moulds  compiled  and  r  ecompiled  a  large 
number  of  times,  tins  mav  indeed  t_«e  prohibitively  excessive.  We 
therefore  believe  that  other  approaches  to  mi cr o-computer  based 
simulation  analysis  that  do  not  involve  compilation  and  'linking 
of  user  written  programs  are  lifeiv  emerge  in  the  near  future  as 
a  more  viable  approach  to  micro  computer  based  simulation 
model  ling. 
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